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BRIEF DESCRIPTION OF THE DRAWINGS 

The invention will now be described in a more detailed manner, with 
reference to the accompanying drawings in which : 

-Rg.l illustrates the three main parts of the RTP/RTCP library according to 
the invention ; « 

-Rg.2 shows in RTP/RTCP library an adaptation layer according to the 

invention ; 

-Fig. 3 illustrates the composition of an MPEG-4 video bitstream ; 
-Ftg.4 illustrates an example of bitstream switching. 

DETAILED DESCRIPTION OF THE INVENTION 

The Adaptation layer of the RTP/RTCP library of Rg.l is depicted in Rg.2. It 
comprises the following sub-assemblies : 

(a) a formatting sub-assembly 21, that receives the input data from the 
current application (receiving stage 211), creates RT packets (formatting stage 212), and 
sends them, with RTP headers, towards the network (Internet) ; 

(b) a retrieving sub-assembly 22, that receives RTP packets from the 
network (receiving stage 221), controls some parameters (control stage 222), and stores 
the data in view of their transmission to the current application (storing stage 223); 

(c) a computing sub-assembly 23, that receives the RTCP packets arriving 
from the network (receiving stage 231), analyses these incoming RTCP packets (analysis 
stage 232), carries out the computation of all the statistical data (in a statistics processing 
stage 233) when RTP packets are received (calculation of the number of packet received, 
deduction of packet loss, delays) and when RTCP packets are received or sent 
(calculation of the error rate), and stores these data in a memory structure. Said 
structure, which can be accessed at the application level, automatically creates the RTCP 
packets (formatting stage 234) and sends them with RTCP headers towards the network. 

According to that implementation, the RTP/RTCP protocol provides to the 
application statistical information about the network status. If the number of packets lost 
is increasing, it means that the available bandwidth is decreasing. It is then necessary to 
drop the server output bitrate so that the user still gets data but with a lower quality (this 
technique allows to have no freeze in the video display even if too many data for the 
transport capacity of the network continue to be sent). 

Two main solutions may be contemplated for changing the output bitrate. By 
using a real-time encoder, it is possible to adjust the bitstream bitrate very close to the 
need. Although efficient, this solution costs a lot of computer power. A second, simpler 
one consists of switching the bitstream while playing : the principle is to have a given 
number N of bitstreams encoded at different bitrates and to just change the bitstream to 
be broadcast when it is needed to change the output bitrate. 



« DIGITAL PROCESSING SYSTEM* 



FIELD OF THE INVENTION 

The present invention relates to a digital processing system comprising a 

user terminal intended to be connected to a network such as the Internet network by 
i ■ ' 

means of a network interface device receiving and transmitting incoming data sent either 

by the terminal or by the network, 

BACKGROUND OF THE INVENTION 

In order to reduce the size of the coded bitstreams associated to any type of 

data information transmitted by communication systems (computer data, digital speech, 

pictures, videosequences, audio data,...), compression techniques are needed. To this 
* 

end, several standards are already available (each one targeting a specific use, such as 
MPEG-2 for digital TV or H.263 for video-telephony). At the same time, with the 
emergence of multimedia applications, the need for interactivity is increasing, which 
implies to encode not only raw data but also information about the content of said data, 
such as hypertext links for example. In case of images, it means that not only a bunch of 
picture elements (pixels) but also a set of semantic relations between these pixels 
correspond to these images : such a representation defines an object When dealing with 
the transmission of that object, not only the signals corresponding to the pixels but also 
said semantic description of the pictures have to be transmitted. 

The MPEG-4 standard has been developed in order to standardize such an 
object-based representation of audio-visual sequences, in view of applications such as 
teleshopping, videogames, virtual exploration, video-telephony and other new interactive 
services. To provide some guality of service (QoS) for these MPEG-4 applications (or 
different levels of QoS accordind to the needs of the applications or of the users, said 
QoS depending on the bitrate, the packet toss, the transmission delay of the packets, the 
drift of said delay, etc..)/ RTP (real-time transport firotocol) is one of the most relevant 
protocols. It consists of two parts, the real-time transport protocol itself, that carries data 
having real-time properties (such as interactive audio and video), and the RTP control 
protocol (or RTCP), that monitors the quality of service (and also conveys information 
about the participants in an on-going session). These protocols (RTP and RPCP) are 
described for instance in the document US 5928331. 

Different solutions may bjp used in order to provide quality of service over 
Internet protocol. They arte assembled in a scxalled RTP library which is designed in a 
generic way and can then be integrated in multiple kinds of applications. The RTP library 
includes the following functions : RTP/RTCP packet creation, data control (buffering, re- 
ordering), statistics computation. As illustrated in Rg.l, three different threads, or tasks, 



constitute this RTP library : the Adaptation Layer (AL), the Asynchronous Port Scanner 

(APS), the Synchronous Port Sender (SPS). 

The adaptation layer AL, provided for constituting a common interface to 

applications that want to transmit data in the RTP format, is used inter alia for RTP 

packetization. The data are indeed transported by RTP in packets (for example, audio 
samples or compressed video data). A data packet consists of a fixed RTP header a list 
(poss.bly empty) of contribution sources, and the transported date themselves (or RTP 
payload). The RTP packets are created by taking the incoming data, received 
asynchronously from the application layer, and packing them into ready-to-send packets 
with RTP headers. Control packets are also provided : a control packet, or RTCP packet 
consists of a fixheader part; similar to that of RTP data packets, and structured elements 
that vary depending upon the RTCP packet type. The adaptation layer, created by a RTP 
session (RTP session = association of participants communicating with RTP, the session 
be,ng defined for each participant by a pair of destination transport addresses) is used 
not only for RTP packetization, but also for updating the statistical data, automatically 
sending RTCP packets, data buffering and RTP packet reordering. 

The asynchronous port scanner APS scans all the session ports in order to 
read the incoming packets, and, from these packets, makes the RTP/RTCP packets and 
gives them to the adaptation layer. 

The synchronous port sender SPS reads all the packets outgoing from the 
application layer and sends them synchronously to the network. 

SUMMARY OF THE INVENTION 

The object of the invention is to propose a RTP/RTCP library with a reduced 
number of handling procedures. 

To this end, the invention relates to a system such as defined in the 
introductory part of the description and in which the interface device is characterized in 
that it comprises : 

(a) means for formatting incoming data received from said terminal into 
packets identified by headers and ready to be sent towards said network ; 

(b) means for identifying packets received from the network 'and forwarding 
them to the terminal ; 

(c) means for managing and controlling the network resources and handling 
the dehvery monitoring service of said packets on the network according to said 
resources. 

According to mis technical solution, the adaptation layer of the RTP/RTCP 
library handles automatically the RTCP packets, and statistics are computed inside the 
library. The user only has to take care of the data connections. 



To implement said bitstream switching, it is proposed, according to the 
invention, to use the MPEG-4 video Access Units feature. According to the MPEG-4 
specifications, representations of multimedia objects of any natural or synthetic origin are 
indeed conveyed from source entities to destination entities in separate elementary 
streams that are encapsulated, i.e. each one of these streams is divided into so-called 
Access Units (AUs) which are individually accessible portions of the coded representation 
of the concerned multimedia object and are the smallest data entities to which time 
information can be attributed in the form of time stamps. As illustrated in Rg.3, an 
MPEG-4 video bitstream is composed of a succession of AUs identified by the indicator of 
time stamps. The principle is then the following : since the server associated to the 
concerned application reads each AU for processing it (decoding or sending it), these time 
stamps will be used to control the switching operations. 

An example of bitstream switching is illustrated in Fig.4. Several source files 
51, 52, 53 (three in said example) correspond to the same video information, but 
encoded at different tartrates, in the present case at 800, 600 and 200 kbits/second. From 
the instant "start time", data are read from an AU source file (for Instance the source file 
51 at the bitrate of 800 kbits/s) and analyzed to get access unit information (by means of 
the "Get Time" function controlled by the server 40, the time stamps associated to the 
AUs are detected). They are then padcetized and the packets thus constituted are sent 
over the network. 

According to the state of the network (by using the RTP/RTCP statistics 
model defined within the adaptation layer, and under the supervision of an AU source file 
switching module 60 included in the server 40), a congestion may be detected (at the 
instant indicated by "congestion detected" in Fig.4). When such a congestion occurs, the 
AU source file switching module 60 activates the "set time" function of the server 40 in 
order to retrieve the time value of the AU concerned by the congestion and to use this 
time value to find the appropriate AU in the other AU source file towards which it is 
wanted to switch (in the present case, the AU source file 52, at 600 kbits/s.). 

Later, when the network conditions become better (or worst), the server 40 
can switch back to a higher (or a lower, respectively) bitrate, using the same method. 



CLAIM : 

1. A digital processing system comprising a user terminal intended to be 

connected to a network such as the Internet network by means of a network interface 
device receiving and transmitting incoming data sent either by the terminal or by the 
network, said interface device being characterized in that it comprises : 

(a) means for formatting incoming data received from said terminal into 
packets identified by headers and ready to be sent towards said network ; 

(b) means for identifying packets received from the network and forwarding 
them to the terminal ; 

(c) means for managing and controlling the network resources and handling 
the delivery monitoring service of said packets on the network according to said 
resources. 



Abstract 

The invention relates to a digital processing system comprising a user 
terminal intended to be connected to a network such as the Internet network by means 
of an interface device. This interface device first comprises means for formatting 
5 incoming data received from said terminal into packets. These packets are identified by 

headers, and then ready to be sent towards said network. The system also comprises 
means for identifying packets received from the network and forwarding them to the 
terminal, and means for managing and controlling the network resources and handling 
the delivery monitoring service of said packets on the network, according to said 
10 resources- 
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